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ae 
| ‘ 1 INTRODUCTION 
; me This Quarterly Technical Report is the current edition in a 
_ series of reports which describe the work being performed at BBN 
: Be in fulfillment of several ARPA work statements. This QTR covers 
Ff 4 work on several ARPA-sponsored projects including (1) development 
fag ¢ 
> ie 
x 64 


of the Pluribus Satellite IMP; and (2) development of the Mobile 


Access Terminal Network. This work is described in this single 


: Quarterly Technical Report with the permission of the Defense 
EK Advanced Research Projects Agency. Some of this work is a 
i. x continuation of efforts previously reported on under contracts 
: : DAHC15=69-C-0179, F08606-73-C-0027, F08606-75-C-0032, MDA903-76~- 
% 


C=0218, MDA903-76-C=0252, N00039-79~C-0386, and N00039~78-C-0405. 
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2 PLURIBUS SATELLITE IMP DEVELOPMENT 
az 
aN 2.1 Introduction 
% 
on 


Progress continued to be made during the quarter toward 


ey stable operation of multiple sites at 3.088Mb/s. In this QTR, we 
2 ran 
Bas, report on current Wideband Network status, operations, and 


performances. In addition, we report on progress in BSAT. 


Progress on BSAT software development concentrated on two 
*. areas. Code to handle the scheduling and managing of channel 
streams was written but has not yet been debugged, and a 


satellite channel simulator for the BSAT based on a software 


Butterfly processor node was designed. A detailed description of 


a the BSAT Satellite Simulator design is given in Section 2.5. 

2 
‘ 
5) 4 
ah 
“ah 2.2 Wideband Network Status 
‘sak 
al ; 
aa One of the major goals for this quarter was to increase the 
ae 
pala number of operational sites in the network. Toward this goal, 
Me the SRI ESI was installed at RADC during October, and the 
¥R 
: Wideband Network gained a third operational site on the 28th, 
ies after ice damage to the earth station's underground waveguide was 
2 repaired. 4 
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9 The earth station installation and check-out was completed 
for both Forts Huachuca and Monmouth during the quarter. The 

8 Fort Monmouth PSAT was installed 19 September. After 
installation, it was left powered down because of a lack of 

ef proper air conditioning. The Fort Huachuca PSAT has aiso been 

Ne: left powered down because of a lack of proper air conditioning. 

$ Testing of the production model of the ESI (the ESI-A) took 

} Place at ISI during much of the quarter and was completed in late 

is October. Production is scheduled to begin in mid-November. 

8 A new version of the PSAT software was released on 5 October 
(release 1.003.00). Many bugs affecting overall system 

| reliability present in previous releases were eliminated, and 

fy several new features were added. Among these were collection of 

b T&M data, an increase in buffer pool size, and facilities for 

9 simplified NOC monitoring and control. 

4 2.3 Wideband Network Operations 

= During the quarter, the Wideband Network operated 

J consistently and reliably in a two-site configuration composed of 

: the ISI and Lincoln sites. Of all the Wideband sites, ISI and 

3 Lincoln were the only ones with sufficient equipment for channel 

FF operation; most of the remaining sites were lacking ESI's. 

8 

A 3 
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Neither ISI nor Lincoln experienced any serious problems 


* during the quarter. Most of the difficulties encountered 


Ls e 
‘ : 
‘, involved small-scale hardware failures in the PSAT. These were 
a 
often remedied by adjusting configurations to include redundant = 
: coaponents. Other failures not covered by redundant components a 
“. were repaired within one day by BBN field service. a 
x > 
xf At the other sites, the PSATs generally ran well. There was f 
R a power failure at RADC in early August that damaged the PSAT. 
4 Be 
The air conditioning system failed to restart after the power ii 
4 failure, and the resulting temperature rise caused overheating in 
the PSAT. After being repaired, the PSAT was kept powered down : 
until a thermal cutoff mechanism could be installed. | 
ay 
a ARPANET/MILNET split tests occurred on 9-10 September and an 
¥ 15-16 September. During these days, BBN experimented with a 
“a alternate site reload and monitoring configurations. Software to sal 
ryt o 
NS load and debug the PSATs using the satellite NU system running on 
5 x 
BBN-INOC was debugged, completing the transition from TENEX-based a 
; to UNIX-based monitoring and control. ra 
ra »: 
ot 
ral a 
2.4 Wideband Network Performance ot 
a On August 1, the Wideband Network task force reported back 
3 
a to DARPA and DCA. They reported that much progress had been oy 
= i 
x k 
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| made, but that reliable 3 Mb/s service involving all Wideband 


Network sites had not yet been achieved. An agenda was 


Pr ta 


established for continued task force activity. The following 


a gt Belk 
om 4: 


: g items were identified as near-term tasks: begin testing two 
x : sites at 3 Mb/s, continue host-level testing of the network, 
: 3 evolve measurement and reporting tools, evolve methods of network 
‘ and subsystem configuration control, begin collecting and using 
5 T&M data to monitor network performance, and begin testing CPODA. 

4 a) 
i ig During August the network operated stably at 1.5 Mb/s, with 


some testing done at 3 Mb/s. An extensive set of tests at 3 Mb/s 
was conducted during the August 22 task force visit to ISI, and 
it was determined that a two-site network operated reliably at 3 
Mb/s with the channel control information coded at rate 1/2. A 


significant number of bit errors in the data were encountered 


| when the speech was uncoded (rate 1). It was found that these 
* o bit errors could be significantly reduced if the speech was coded 
; “ at rate 3/4. 
ae 
: of Lincoln Labs and ISI cooperated in channel throughput 
4 a performance tests on 29-30 September. Two simultaneous 
: z telephone-to-telephone connections were sustained, in addition to 
_ other looped voice connections from Lincoln. These tests 
¥ represented the highest voice traffic load yet carried by the 
4 + Wideband Satellite Network. 
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2.5 BSAT Satellite Simulator 


This section describes the design of a software-based 
satellite channel simulator for the BSAT. The primary function of 
the Satellite Simulator is to connect multiple BSATs into a 
network via a simulated satellite channel. In this role it must 
provide the approximately 1/4-second propagation delay that would 
be expected over a channel supplied by a geostationary satellite 
such as WESTAR. It must also simulate the multiaccess/broadcast 
capability of a satellite channel. This requires merging the 
bursts of data transmitted by different BSATs so that any 
transmissions that arrive at an actual satellite at the same time 
result in corrupted data on the simulated satellite downlink. 
The merged satellite downlink data must be received by all of the 
connected BSATs. In addition to the channel, this simulator will 


simulate the functions of the Earth Station Interface (ESI) 


(modem/codec) supplied by Linkabit. 


Satellite simulators performing the primary function 
described above have been built out of dedicated digital 
hardware. The burst merging function was provided by logically 
ORing any bits that were clocked into different input ports of 
the simulator at the same time. The resulting merged data were 
then delayed for one Round Trip Time (RTT) before being clocked 


out of each of the output ports. Such simulators have proved 
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themselves quite useful for the development and debugging of 
those components of Satellite IMP software that can only be 
properly exercised in the presence of actual satellite delay or 


in a multienode network environment. 


The BSAT Satellite Simulator will be different from the 
satellite simulators described above in that it will be 
implemented as application software running under the control of 
the Chrysalis operating system on a Butterfly Multiprocessor. 
Such an implementation has been chosen for compatibility with the 
current BSAT. The latter also runs in the Chrysalis/Butterfly 
environment and expects to access the satellite channel via an 
ESI connected to one or more of the serial synchronous 1/0 
channels provided by the standard Butterfly I/O (BIO) board. The 
ESI is expected to be an intelligent device providing such signal 
processing functions as data encoding/decoding, 


modulation/demodulation, etc. under the control of the BSAT. 


With a software realization of a satellite channel 
simulator, it is easier to simulate the behavior of the actual 
ESI to which the BSAT would be attached. This includes the 
exchange of local control packets between the BSAT and the ESI 
(used by the BSAT to read/modify ESI parameters, read the value 


of the ESI's local time clock, set loopback modes, reset the ESI, 


etc.) and discarding (before delivery to the BSATs) any burst 
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whose preamble or ESI control area was corrupted by a collision 
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* 
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at the satellite. Additionally, it is easy for a software 
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simulator to keep a variety of useful statistics on the traffic 
traversing the satellite channel and the BSAT-ESI interfaces. 


Such functions are included in the current design. 


LARS OL LS 


A software implementation also makes it easier to simulate 


such satellite channel characteristics as uplink noise, downlink 


rr ‘noise, RTT drifts, etc.. These functions, and other possible test 
functions, will not be implemented in the initial Simulator; 
i however, it is hoped that the current design will facilitate 
* 

a their possible insertion at a later date. 

on 2.5.1 Model of Simulator Operation 


2.5.1.1 Delay Function 


* The burst packets submitted by the BSATs to the ESI for 
34 transmission over the satellite channel will be stamped with a 
sd 32-bit "local® time. This time is in units of 1/3.088 x 10##-6 
2 sec. A clock is expected to run at this rate in the ESI and the 
= time stamp indicates the clock's value for the burst preamble 
a tranmission time. Bursts are passed to the ESI up to two PODA 
S frames before the indicated local transmit time (“40 msec). When 
~ the ESI acquires a burst from the satellite downlink, it prepends 


aah ot eg Ses 


3 
i | 
e Report No. 5492 Bolt Beranek and Newman Inc. : 
oy ee 
@ the burst preamble's receive time (again in units of the ESI's re) 
, local time clock) to the burst data before passing it to the 
ia ee 
ns) BSAT. All bursts are received at the BSAT sites after an mee 
appropriate satellite propagation delay. ‘el 
a os 
a4 The BSAT Satellite Simulator will duplicate this function as woe 
oi closely as possible. Different RTTs for the different connected i 
a BSATs will be supported by performing the burst merging function “te 
‘ BY. 
with times normalized to "satellite" time and delaying the merged a4 
PAN (satellite downlink) data different amounts of time for each pnt 
rh BSAT. There will be tolerance parameters for both how far se 
nd es 
tw before, and how far after, an indicated local transmit time a a 
oe 
oa burst may be received from a BSAT for transmission by the r 
Simulator. (BIO latencies may cause the burst to appear late.) ae 
~ he 
3 co 
ay 
ae 
a ae 
iat wing 
aad 
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by 

Ss 

2.5.1.2 Burst Merger and Reception 

ie 

y 

S) 

A transmitted burst is modeled in the Simulator as follows: 

> T1 T2 T3 Th 
i : "4 peewee ne Gen deer oen toe ee Se S oe e $2288 22802200 SUSONSe fe Tee Te222noo nen > 
" ! ! 1 | | 
* {| PREAMBLE | ESI CONTROL INFO | BSAT CONTROL INFO | OPTIONAL MSGS | 
3 ! ! } ! ! 

doeee reese wemwe ew ee ewe fee seen ween ew eewwn fee eww eee cewe nnn + 

or 

By 

“| The PREAMBLE is used by the ESI to acquire the burst. The 
a Simulator will drop (will not return to ANY of the BSATs) any 
ces burst whose PREAMBLE's satellite time coincides with 

4 transmissions from any other BSAT. It is also assumed that an 
rf) 

is ESI cannot acquire bursts transmitted at symbol rates different 
‘ than that specified by the ESI's receive symbol rate parameter. 
aM The Satellite Simulator's downlink process for a given connected 
3 BSAT will therefore drop any bursts transmitted with symbol rates 
* different than the BSAT's receive symbol rate. 

4 

re 

4, The ESI CONTROL INFO is used by the ESI to determine the 
-— 

type of demodulation and decoding to be performed on the 

zl remainder of the burst before it is passed to the BSAT. It is 

+ {] 

5 protected by a checksum field inserted by the ESI on transmission 
ee and checked on reception. It is assumed that the ESI will drop 
¥ any bursts with bad checksums; hence the Simulator will drop any 
- burst whose ESI CONTROL INFO's satellite time coincides with 
B 

3 10 : 
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a cs 
ft 
‘ : 
| transmissions from any other BSAT. A further assumption is that 2 
7 acs 
é a receiving ESI must have the same "state-1" modulation type and 
4 hae 
A 
hts coding rate as a transmitting ESI in order to decode a burst 
e properly; hence the Simulator's downlink process for a given 
st connected BSAT will drop any bursts transmitted with non-matching 
yi state-1 parameters. 
z The BSAT CONTROL INFO is used by the BSAT for channel = 
4 ar 
Vv “ 
: aie protocol operations. It is transparent to the ESI and is < 
, “ protected by a checksum field inserted and checked by the BSAT. 


If the transmissions from any other BSAT coincide with this part 


of a burst (and the burst's PREAMBLE and ESI CONTROL INFO are 
clear) the Simulator will return the burst packet to the BSATs, 
but with corrupted bits in the BSAT CONTROL INFO area. (This 


uN 

presumably will cause the BSATs to detect a checksum error and : 

discard the burst packet.) x 

is The OPTIONAL MSGS are the host messages and message headers ~ 
; 3 being transmitted by the BSAT. They are transparent to the ESI, = 
‘ e and may or may not be protected by various checksums. This burst ™ 
24 section is handled by the Simulator in the same fashion as the : 
4 BSAT CONTROL INFO. : 
- t 

he aaa The Simulator's burst merging algorithm operates on time " 
d i" values normalized to a 3.088 MHz "satellite® clock. The 3 
| satellite times for the different parts of a burst are indicated = 


id 
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oe 
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rs, 
i 
: as {T1,T2,73,T%} in the diagram above. 11 is the time of 
a PREAMBLE start derived by the Simulator from the burst's 
a transmission local time stamp and the BSAT's current RTT. TH is 
a 
derived from T1 and the BSAT-supplied "burst length" and "symbol 
ode rate" fields. The derivations of T2 and T3 additionally require 
TAR 
a Simulator parameters that may be a function of the state-1 
y 
as 
modulation type and coding rate, as well as the exact burst 
Bs format being used by the BSAT. 
my 
3 A collision will be deemed to have occurred, and the 
2 appropriate action (as described above) will be taken, when any 
s 
y part of a given burst area is in contention with another BSAT's 
= burst. Data corruption will probably be done by complementing a 
wy few selected words in the given burst area. 
‘a 
ES 
RY 
y 
2.5.1.3 Local Control Packet Exchanges 
% 
<i] The Simulator will emulate ESI responses to BSAT commands to 
) 
ae set/read its operational parameters. Some of the parameters, 
Mt such as preamble length, will have an effect on Simulator Be 
al ae 
is operation; other parameters will simply be stored. A BSAT will 
ne4 ay 
= also be able to reset and loop its Simulator port. The REQUEST ws 
x LOCAL TIME and LOCAL TIME REPLY packet exchanges needed by BSATs x 5 
> sO 
to derive global time from their Butterfly processor clocks will : 
OM 
be supported. If the BSAT generates ACQUIRE GROSS FREQUENCY ig i 
: 
a 12 a 
Ps ‘ 
ad d 
a 
% ye Aah 
fia"s : 
ae sD Ne may ree: Pa raeke sean a eae es Nn ind Lae nara a nee ~ 5 soe gee Pe Bere Ru ve 
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OFFSET, BUILT IN TEST, or similar packets, canned responses will 
be returned by the Simulator. ILLEGAL LOCAL CONTROL PACKET 
RECEIVED and PROTOCOL ERROR packets may also be generated by the 
| Simulator. T&M RESULTS will not be supported. 


“4 The Simulator software is structured to provide 


4 


a. independent control of each BSAT interface for looping, 
resetting, and parameter manipulation operations, and 


hr 

% b. transmission of local control packets to the BSATs as 
quickly as possible. (They will be pushed to the front 

em of the queue of items to be sent to a BSAT and will not 

wai be subject to any propagation delays.) 


2.5.2 Simulator Hardware Configuration 


4 Svcs 
wale 


a The Satellite Simulator will communicate with connected 
a; BSATs via the serial synchronous I/0 channels provided by the 
4 


eurrently available BIO boards. Note, however, that most of the 


SMM NAA: 
worse 


p Simulator software will be independent of the specific Butterfly 
I/O boards being used, so that it will not be difficult to adapt 


the Simulator to new boards as they become available. 


| eae SSAA. 
wee 


@ 

Bs The Simulator (and the BSATs) must deal with the current 

a bandwidth limitations of the BIO channels, the BIO 

ay 

v microprocessor, and the Butterfly I/O bus (the BIOLINK). Two of 
- these limitations are the following: 
ae 

| 
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o Each channel has a limit of 2 Mbps in each direction. 

im © The BIO microprocessor can handle an instantaneous data 
y rate of up to about 5 Mbps. 
These numbers are significant in light of the fact that the 
Wideband network runs at satellite channel data rates of up to 
y 3.088 Mbps. If such high-rate operation is to be supported, it 
: is necessary to use two ports for each BSAT-to-ESI connection and 
two ports for each ESI-to-BSAT connection. The second limitation 


above permits only two of these ports to be located on each BIO 


dite yas cl: 


board; each complete BSAT-ESI interface would therefore require 
f two BIO boards for 3.088 Mbps operation, and a BSAT Satellite 
: Simulator connected to two BSATs would require four BIO boards 
: (not to mention the other four BIO boards required by the two 
. BSATs) . 


To keep the number of needed BIO boards down and to simplify 
the initial BSAT-Simulator integration, each BSAT-Simulator 
connection will initially use a single 2 Mbps channel in each 
direction. In order to accommodate the current BSAT 
implementation, this will be done with two half-duplex ports 


rather than a single full-duplex port. 


Another issue is the number of Butterfly processor nodes 


that will be needed to support the Simulator. The Satellite 
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Simulator will most often interface to only one or two BSATs 
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elt 

qf, 

ie a 
| (although nothing in the structure of its software will prevent 

: ; it from handling a greater number of BSATs). As discussed above, a 
wk 

: hy a twoe-BSAT configuration will initially require two BIO boards. 


These boards could conceivably be connected to a single processor 


ee 

: e node. This would have the advantage of allowing the Satellite 
fom 

‘ 2 Simulator to live in the same Butterfly machine as a BSAT without 


perturbing the BSAT's operation, since the all of the Simulator 


software would reside in the single node and would not do any 


‘a Rae at pe 
i ‘i ¢ 


B accesses across the Butterfly Switch. This consideration aside, 
‘ it is probably best to support a two-BSAT Simulator with a 
; R minimum of two processor nodes, each interfaced to a BIO board. 
3 This configuration has the advantages of not requiring the 

i movement of BIO boards from their standard lab configuration when 
i Ae the Simulator is to be run, and it provides the Simulator with 
t more physical memory for its satellite delay function. 


? oh 
= A two-BSAT Simulator will therefore look like: 
2% oe qemmwenn > fwwwenn+ ey eo 
- 2 Mbps ->|BSAT #1! |PROC' R| {PROC'R} IBSAT #2 |<= 2 Mbps 
acd ! BIO {-BIO-{NODE [<--~--->/NODE {-BIO-} BIO | 
mi 2 Mbps <-| | LINK] #1 | B'FLy | #2 | LINK! [=> 2 Mbps 
’ pememmme quonnnn+ SWITCH teeeon=+ qe eeesene+ 
4 Z OR 
as poeswecn+ qrecese + shew erence qeeceonoe+ 
Rie 2 Mbps ->|UPLINK | | PROC’ R} {PROC'R| |DOWNLINK|=> 2 Mbps 2 
oes | BIO [=BIO-|NODE |<—-~--->{NODE |-BIO-! BIO | y 
} 2 Mbps ->/ | LINK] #1 {| B'FLY | #2 | LINK! |~> 2 Mbps 3 
fy jromseea+ queeee~+ SWITCH teoonnn+ qeeeeoenn+ zi 
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The process structure of the Simulator will be able to 


to 
+ Wad 


uf handle either of these configurations. Which configuration to 

oe i 4 

rs use will be determined by the performance observed during BSAT- oe 

*% 

a Simulator testing. = 

a ws 

as! 

mS, > 

ee a 

bass 2.5.3 Simulator Software & 

RY Like the BSAT software, the Satellite Simulator software = 

re . 

a! 

wy will be implemented as a set of C-language~coded processes : 
running under the control of the Chrysalis operating system. a 

3 Some of the BSAT program's functions will be employed for use by ee 

ye the Simulator where this seems efficient. The Simulator software 

—Y pa 
will be structured so as to be independent of the number of | 

ag connected BSATs, the number of physical ports used to connect s 

ou a 

2 each of the BSATs, and the location of the physical ports. Five 

5 kinds of processes make up the Simulator application: bi 

* a. Synchronous I/0 driver processes (receive-only or 

Pe. transait-only). ; we 

p On os 

ous b. Uplink processes. ° 

“ = 

ac ec. Downlink processes. at 

nt 

a d. One merge, or satellite process. 

Se e. One system initialization/control process. “ 

75, The processes are described in the following sections. ‘ 

5 “ 
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g 2.5.3.1 Synchronous I/O Driver Processes 
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There will be one of these processes for every physical port 


“we 
* 


¢ 


that is connected to a BSAT. Each process will operate in either 


= re a transait-only or receive-only mode, since the BSAT software 
(a 

* a does not use full-duplex ESI connections. Both the transmit-only 
oy OR 

e wey and receive-only processes will be linked together and loaded as 


2 single Chrysalis process template; one of the arguments passed 


to each separate invocation via Make_Process will be used to 


LPL SP 
Eatds 


ied 
S inform the invoked process of its direction. This is like the 
"process group® notion used in the BSAT software; it is intended 


ne to minimize the amount of physical memory used for process text 


segments when a number of different process types use many common 


routines. 


All of the management and much of the initialization of 


ASE aly 
22a 


; E CCBs, I/O device control registers, the transmit and receive 
i 2 queues used by the BIO microprocessor, etc. will be performed by 
3 ¥ routines developed for the BSAT. These routines will be changed 
i | as little as possible. The process initialization, startup, and 
; . event dispatching code, as well as the routines providing the 
> S interface to the uplink and downlink processes, will be unique to 
i the Simulator application. 
u Since an I/0 driver process must access the I/0 device 
1: 


ky 


control registers for the physical port it is managing, it must 
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run on the processor node to which the given port is attached. 
It will map in all of the buffer pools located on the processor 


node. 


A receive-only I/0 driver process interfaces to a single 
uplink process through two dual queues: a receive-request queue 
and a task queue. The receive-request queue is used to pass 
packets received on the physical link to the uplink process, and 
the task queue is used by the uplir. process to control. the 
synchronous channel's modes/parameters. Packets suffering 
overruns or aborts will not be passed through to the uplink 
process; however, packets with CRC errors will be passed on to 
higher-level processing. An extra header word will be added to 
each packet indicating the total number of bytes in all of the 
buffers making up the packet. 


A transmit-only I/0 driver process interfaces to a single 
downlink process through two dual queves: a transmit-request 
queue and a task queue. The transmit-request queue is used to 
pass packets from the downlink process to the I/0 driver for 
transmission over the physical link, and the task queve is used 
by the downlink process to control the synchronous channel's 
modes/parameters. The I/0 driver process splices the packets 
found on the transmiterequest queue into the BIO transmitter's 


CCB queue in accordance with the values in the timestamp field of 
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the buffer headers. This timestamp value determines the earliest 


time of transmission of the packet to the BSAT; it is calculated 


2 by the higher-level uplink, downlink, and merge processes. z 


# 
Z 
5 

% 


2.5.3.2 Uplink Processes 


CARLA 
wow 8: 


There will be one of these processes for every receive-only 


& z I/O driver process. If each BSAT is connected to the Simulator r 
z by two physical links, there will be two receive-only I/O drivers 

. a and two uplink processes per BSAT. Each uplink process 

i 3 communicates with its corresponding I/O driver via a (private) 

y a pair of dual queues as previously described. In addition, each 

: a uplink process communicates with: 


a. the merge process via a private uplink queue containing 
burst packets to be sent over the simulated satellite 


SWRPA 
Pee 
i 4 
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channel, 

| b. a downlink process via a downlink dual queue containing 
& local control packets and burst packets for transmission 
Y to the BSAT with which the uplink process is associated, 
ae and 
te) 
< ce. the same downlink process via a common memory segment. 
aa? 
x There will be a separate uplink queue interfacing each 
4 oc 
x Ri uplink process to the merge process. The duplication of the 
: rte) 

: processes/queues handling uplink data for multi-ported BSATs ‘ 
ae) allows flexibility in the placement of the physical ports 
D 
s “s handling BSAT input. Also, since the merge process must handle : 
- =| oo 
4, . 
A ? 
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the time ordering of bursts from different BSATs, it is simplest 


to let it also handle the ordering of the bursts from a multi- 


ported BSAT. x 


An uplink process acts as a filter, passing non-looped burst 


A packets to the satellite (the merge process) via its uplink 


queue, and looped burst packets and local control packet ue 


responses back to the BSAT via a downlink queue. An uplink ae 


process will not (except for processing/scheduling latencies) 


delay or re-order burst packets; this allows local control id 


packets to be serviced quickly. It is assumed that the burst 


fe Sat Fl 


Par a are 


packets arrive at the Simulator in transmit-time order. (The 


‘tere 
a. 


paty of 


- 


merge process discovers out-of-order packets.) 


Most of the satellite propagation delay to be suffered by ~ 


burst packets will be waiting on an uplink queue for service by 


the merge process. Given current estimates of both buffer size Ls 


and the waiting time on this queue, a ring-buffer-oriented dual 


queue will probably be usable. However, a linked list with 


appropriate interprocess dual-queue locks and events could be = 


used if memory space is tight. 


When a non-looped uplink process receives a burst packet, it = 


* ns 28 8 Se 


derives the BSAT Simulator local time of the packet's arrival 


from a time stamp placed in the buffer header by the I/0 receive 


Pr a. oe ee 


process and does a validity check comparing the resulting value 


. 
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with the packet's specified local ESI transmission time. The 
transmit time field of the packet is then incremented by 1/2 of 
the RTT value (in 3.088 MHz local time units) for the BSAT in 
question, normalizing it to a common satellite time for the merge 
process. The buffer header time-stamp field is adjusted to be 
consistent with the local transmission time and is then 
incremented by 1/2 RTT + K (in 16 KHz Butterfly time units). XK 
is a Simulator parameter whose optimum value must be determined. 
Since the buffer header time-stamp field is used by the merge 
process to determine when to process the burst packet and send it 
to the downlink, larger values of K will reduce the buffering 
demands on the Simulator by forcing necessary downlink copying 
operations to occur closer to the time of burst packet delivery 
to the BSAT. If K is too large, however, bursts may arrive at 


the BSATs too late. 


An uplink process will insert information needed by the 
merge and downlink processes in an extra buffer header word 
(e.g., the burst's state-1 modulation type and code rate, 
preamble size, an indication that the burst went via satellite 
rather than being looped). The buffers will then be placed on 


the appropriate uplink queue. 


Most of the processing of a BSAT's local control packets is 


done by an uplink process. If the processing results ina 
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response that needs to be sent to the BSAT, the response is 


a written into a buffer and the buffer is placed at the HEAD of the 

downlink queue associated with the BSAT. The buffer-header 

° timestamp field is set up so as to axpedite the transmission of 
<3 the response to the BSAT. If local control packets change the 
Et Simulator's parameters for the BSAT, or if they reset or loop the 

j Simulator/BSAT interface, such changes will be reflected in the 
3 common memory segment. 
we If an uplink process is in a looped state as a result of a 

we LOOPBACK local control packet, burst packets are flagged in a 

s header word as having been looped and are placed directly on the 

“i associated downlink queue. The local ESI transmission times of 

. the packets are checked for validity. There are no other 

3 modifications/operations on the packet. Local control packets 

uy will be processed normally when an uplink process is looped. 

- An uplink process must map in all of the buffer pools for 

xy the processor node on which its associated receive-only I/0 
se driver is located. 
: 

ity The functions performed by an uplink process’ could 
» conceivably be incorporated as part of the "user" subroutine 
Eo invoked by the receive-only I/0 driver process. A separate 
FS process will be used, however, since the uplink functions are in 
ay a sense “higher level® than the functions needed to manage the 
= ~ 
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1] 

i 5 associated I/O hardware. (This is analagous to the distinction 
in the BSAT between HAP-level and HostIO-level processes.) The 

‘ os same distinction is made on the downlink side of the Simulator, 


which is discussed below. Such process separation may simplify 


the implementation of future uplink and downlink Simulator 


kate 
ue 


oe functions, such as the insertion of satellite channel noise. 


* ie 
ames 
: 2.5.3.3 Downlink Processes 
WN 
; There will be one downlink process for each BSAT attached to 
Ey a the Simulator. A downlink process communicates with either one 
os ‘a3 
or two transmit-only I/0 drivers, depending on whether its 
. a associated BSAT is connected to the Simulator by one or two 
2 “d physical links, respectively. The interface to each I/0 driver 
7 oy 
i consists of a separate pair of dual queues, as previously 
x bs described. In addition, each downlink process communicates with: 
%e 
| xd a. the merge process and one or two uplink processes via a 
‘s) dual queue containing local control packets, looped 
~_ burst packets, and non-looped burst packets destined for 
-— the given BSAT, 


b. the same (one or two) uplink processes via a common 
memory segment. 


oN 
Pe 
a A downlink process passes looped burst packets found on its 
Fed 14 
eel 
be it queue to aie transmit-only I/0 driver without making any 
ro modifications to the packets’ contents. When a non-looped burst 
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~. 

: packet is received (from the merge process), loop and reset re ? 
“ indicators located in the common memory segment are checked. If 4 
iy the BSAT is looping or resetting the Simulator, all of these oe : 
j packets are dropped, effectively filtering out the BSAT's cs ff 
A satellite downlink. 

4 

¥" 


A downlink process assumes that the non-looped burst packets 
found on its downlink queue have been merged: They are found on iat 
the queve in satellite-time order with their satellite times in 

Ba the local transmit time field and (possibly) corrupted bits in : 


their BSAT CONTROL INFO or OPTIONAL MSGS areas. 


When the Simulator is not being looped or reset by the BSAT, ; 7 
the merged burst packets are processed as follows: The channel | 
symbol rate and the state-1 modulation type and coding rate of 
.: the packet are compared with the current values of these 
parameters for the receiving BSAT (found in the common memory 
Pe segment). A packet with a mismatch is dropped. The local 
transmit time field is then incremented by 1/2 RTT for the 
downlink BSAT (plus the burst's preamble size), to provide the 


BSAT with the correct local receive time. The local receive time 


( is then used to calculate a BIO transmit time, which is placed in 


the buffer header time-stamp field for use by an I/O driver. The 


‘ 
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: packet is then placed on a transmit-request queue for processing 
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pe! by an I/0 driver. | 
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A downlink process performs (minimal) processing on any 
received local control packets and passes the results to an I/0 


driver. 


When there are two transmit-only I/0 drivers per BSAT, it is 
important that they each receive about 1/2 of the bandwidth of 
data being transmitted to the BSAT by the downlink process. The 
downlink process will attempt to equalize the amount of data sent 


to the two I/O drivers by using the total data size field 


provided with each packet. This can simply be done by 


oe 6] maintaining the difference between the number of bytes sent to 
a driver #1 and driver #2 as a signed integer. If the number is 
» ii positive, the next packet will be sent to driver #2, and its size 


will be subtracted from the number; if negative, the packet will 


be sent to driver #1 and an addition will be done. This scheme 


ig OAT MEL 
Oe ek 
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is better than equally dividing the number of PACKETS sent to the 


Ex | 


¢ 


I/O drivers, since it weights the packets by their quantity of 


transait data. 


) epee: 
a 


x 2 Any packet that is to be sent to an I/0 driver by a downlink 
Wy process must be copied into physical memory on the processor node 
® 4 on which the I/O driver (and the corresponding I/0 port) is 
‘ located. Also, the downlink process cannot write into the 
3 3 original copy of the packet, since it may be shared with other 
z § downlink processes. In order to perform all of the possible copy 
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operations, a downlink process must map in all of the buffer 
pools on any processor node with a receive-only I/0 port, as well 
as all of the buffer pools on the processor node(s) hosting the 


transmit-only port(s) for the associated BSAT. 


A downlink process will not (except for 
processing/scheduling latencies) delay any of the packets it 
receives. Any explicit delay, beyond that already suffered by 
the packets while waiting on an uplink queue, will occur while 


waiting on a synchronous transmitter's queue. 


2.5.3.4 Merge (Satellite) Process 


The merge process (Merge) simulates the broadcast and 
multiaccess functions of a satellite. As such, it tries to 
remain as independent as possible of the state of the remainder 
of the Simulator. (For example, the merge process has no 
knowledge of the fact that a given BSAT interface is in a_ looped 
state.) The interfaces to the merge process are the uplink 
queues, each containing the non-looped burst packets from a 
single uplink process, and the downlink queues, each identically 
containing the results of the satellite merge for transmission to 


a single downlink process. 
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The merge process does not associate the (two) uplink queues 
that may contain packets from the same BSAT; it only expects that 
the satellite times found in the local transmit time field of the 
packets in a given queue are in increasing order. Under this 
assumption, Merge always processes the packet at the head of a 


queue before inspecting the contents of any following packets. 


For the packet at the head of each uplink queue, Merge 
calculates the {T1,T2,T3,T4} values describing the sections of 
the corresponding burst. The T1 values are then used to sort the 
bursts at the heads of the uplink queues by increasing PREAMBLE 
transmission time. Merge then determines a decision time, and 
dismisses until that time has passed or more burst packets arrive 
(on any uplink queues that had previously been empty). The 
decision time is the real time indicated in the buffer header 
timestamp field (1/2 RTT + K, inserted by uplink process) of the 
packet at the head of the sorted list. When any new packets 
arrive on previously empty uplink queues, the sorted list and 


decision time is updated and Merge again dismisses. 


When the decision time has passed, a merge decision is made 
using the model described in "Burst Merger and Reception” above. 
Each decision has one of five possible results: 


a. The packet at the head of the list sorted by T1 values 
is passed unscathed to the downlink, 
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b. the head packet is passed to the downlink with its 
OPTIONAL MSGS area corrupted and the next packet on the 
list is dropped, 

ec. the head packet is passed to the downlink with its BSAT 
CONTROL INFO area corrupted and the next packet is 
dropped, 

d. the head packet and the next packet are both dropped, or 


e. only the head packet is dropped. 


Merge advances a satellite time pointer every time it makes 
a new decision. This pointer defines the satellite time up to 
which decisions have been made. It is also used to detect 
packets that arrive either out of order or too late on their 
uplink queues; such packets will be dropped. For example, if 
Merge makes a decision with an outcome of type "a", the satellite 
time pointer would be updated to be equal to the T4 value of the 
burst packet being passed to the downlink. (T4 defines the 
satellite time of the end of the burst.) This is done to reflect 
Merge's decision that the burst has not suffered a collision with 
any other burst at the satellite. If a burst packet were then to 
arrive on an uplink queue with a T1 value (defining the beginning 
of the burst) that is earlier than the satellite time pointer, it 
would be dropped. The packet is dropped because (1) its T1 value 
may be such that it would invalidate the (irrevocable) decision 
that the previous packet suffered no collisions, and (2) its T1 
value may be such that the packet would be passed to the downlink 
out of satellite time order. 
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The value of K used to adjust Merge's decision times must be 


large enough to account for any latencies suffered by a packet 


before reaching its uplink queue. If the value is too small, 


packets may be unfairly dropped by Merge for tardiness. 


In order to perform its functions, Merge must map in all of 
the buffer pools on every processor node with a receive-only I/0 
port. Merge passes a burst packet to the downlink by placing a 
pointer to the packet (the buffer ID for the packet) on each of 
the downlink queues. The downlink processes will then make their 


own private copies of the packet. 


2.5.3.5 System Initialization/Control Process 


The BSAT Satellite Simulator will have aie single 
initialization/control process (Init). The initialization scheme 
to be used for the Simulator is similar to that used for the 
BSATs. Init will be loaded into a Butterfly Multiprocessor node, 
and will be invoked via the Chrysalis operating system's user 


interface. 


When Init starts to run it will allocate and map in a memory 
segment referred to as the "common segment." The common segment 
will be mapped in by all of the Simulator processes and will be 


used as a means of interprocess communication. Most common 
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segment data entries will be single words or bytes defined as 
write-only by one process and read-only by other processes; this 
avoids waiting on locks for common segment accesses. Some of the 


common segment contents are indicated below. 


Init will perform TTY I/O with the Simulator user in order 
to determine the desired Simulator configuration/parameters 
(e.g., how many BSATs are to be supported, which nodes the 
various Simulator processes are to operate on). The 
configuration/parameters chosen will be entered in the common 
segment. Init will then make the appropriate calls to 
Make Template and Make_Process for each desired process in turn, 
passing the OID of the common segment and other configuration 
information as arguments 1 and 2 of each process invocation, 
respectively (e.g., for an uplink process, the BSAT number and 
physical link number are passed in argument 2). When each process 
runs, it will peform various initializations and will create 
assorted Chrysalis objects (primarily event blocks, dual queues, 
and channel control blocks, but NOT buffer pools). The object 
handles of the objects that are used for interprocess 
communication are published in the common segment. When 
initialization is complete, the process will signal Init via an 
event handle found in the common segment and dismisses; Init will 


then invoke the next process. 
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When the last process has signaled Init that its 
initialization is complete, Init creates buffer pools occupying 
most of the remaining memory on each processor node that has 
synchronous I/0 ports. Again, the object handles are published 
in the common segment. Init will then signal each proecess in 
turn. When each process is so signaled it will use entries in 
the common segment to map in its required buffer pools, make 
local copies of interprocess queue handles, etc. The process 
will then enter its main loop and will signal Init that it has 
done so. The receive-only I/0 driver processes will be the last 
processes to be started by Init; this is done to prevent packets 
from waiting on queues for service by a process that has not yet 


entered its run mode. 
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Once all of the processes have signaled Init that they are 


at 
“e 
‘ 


running, Init enters a control mode, where it again interacts 


a 


with the Simulator user. In this case the user is given control 


of TTY display of Simulator statistics. It is expected that 


there will be sany Simulator statistics kept in the common 


“a 


segment by the various processes. Init should provide a facility 


to take snapshots of these. The user will also be given 


“wt 
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mechanisas to alter various Simulator parameters, reset the 


Simulator, etc. 
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3 MOBILE ACCESS TERMINAL NETWORK 


Oe 


Our participation in the development of the Mobile Access 
Terminal (MAT) and the MAT Satellite Network (MATNET) during the 
last quarter was reduced to a low-level support while waiting for 
contract renewal. We did, however, participate in several 
meetings with Navelex to discuss the next-generation MATNET 


systen. 
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